In an object-oriented software component environment, developers utilize development tools at design time to create user applications. Software components may be written by various suppliers in a variety of source languages. The user applications are then implemented at run time.
Conventionally, during design time, a development tool typically reports a static set of information (e.g., properties) about a component to a developer. Thus, conventionally, component information is static and provided by the compiled component to the development tool when the development tool is constructed (e.g., compiled). Changes in the component are not reflected in the development tool dynamically; generally only the information known about the component at the time the development tool was constructed (e.g. compiled) is available to the developer. The development tool is thus unable to effectively utilize changes in the component unless and until it is reconstructed (e.g., recompiled).
In a design time environment, in order to use a component, a development tool typically creates an instance of the component. The development tool generally utilizes an engine to report information (e.g., properties) associated with the component that is reported to the developer. Thus, the developer can manipulate the component utilizing the information (e.g., properties) associated with the component.
Conventionally, development tools are able to obtain properties from the component that provide limited information to the developer—any special behavior had to be provided for by the development tool (e.g., Visual Basic or Visual C++). Thus, at design time, in order to simulate the run time environment, the development tool provides additional properties to a component through extender properties that the development tool provides on the component's behalf. The development tool merges these extender properties into the flow of properties, which introduces additional complexity, and thus additional costs into the development of the development tool. Similarly, certain properties should not be exposed at design time; these properties should only be exposed at run time. The development tool and/or the component must know the particular properties that should not actually change control at design time. The development tool and/or the component remove these particular properties from the flow of properties.
For example, a component that includes a database query should not execute the database query at design time. Instead, at design time, the developer may desire to have the query stored until run time without having the component execute the database query. Presently, the component and/or the development tool implements the design time implementation of blocking the database query execution at design time.
Thus, conventionally, implementation of the design time environment has been an awkward cooperative effort between the component and the development tool. From the component side, the component inquired as to whether it is in design mode and then took no action based upon the data it received during design time. Alternatively, the development tool could merge in additional properties or pull properties off of the set of properties that are exposed in order to implement the design time environment. However, the development tool maintained a static set of information about a component. In order to update or modify information about a component, the development tool would need to be recompiled and reissued as a new release of the development tool.
Thus, at present development tools and/or components must implement a method and system for the design time context of components. This design time implementation is compiled into the development tool and/or components is inflexible and is very complex.